Currently, the requirements for layer 2 access devices put forward by telecom operators are higher and higher. Layer 2 devices are required to distinguish services based on layer 3 information, so that different services, such as audio, video, Internet and so on, can be distributed in access devices like the Digital Subscriber Line-Access Multiplexer (DSLAM) and access to corresponding service networks via gateways corresponding to different services. Concretely, operators will generally plan service networks in advance, and different service providers possess different IP addresses. In this way, access devices can distinguish and forward services based on destination IP sub-networks. However, common access devices are only layer 2 devices and not used as user gateways, therefore these access devices are transparent to users in the third layer. Moreover, they don't have dedicated IP addresses for forwarding data. Therefore, accordingly, the network can only create unnumbered IP interfaces to meet this requirement. And this is also used to cope with the requirement for saving IPv4 addresses which are becoming scarcer.
Presently, there is a method for creating route tables by monitoring route protocol messages. But operators normally don't enable route protocols on the ports on the user side. Route protocols based on link statuses (e.g. Open Shortest Path First) normally requires the correspondent node to have layer 3 addresses, however, this requirement can not be satisfied. Although route protocols based on distance vectors (e.g. Routing Information Protocol) are usable, restrictions are put forward when operators choose route protocols, and employing route protocols in the user-end network increases the complexity of the network and the load of the layer 2 network. Since layer 2 devices should support route protocols in this way, higher requirements are put forward for them.
Generally, it is very difficult for layer 2 devices to obtain layer 3 route information. Configuring each such access device statically not only leads to high work load, but also makes layer 2 devices lose their advantage of plug&play. Thus, this becomes a relative prominent problem.
The present invention proposes a method and an apparatus for distinguishing services and forwarding data based on destination IP sub-networks by creating routes on layer 2 devices via the use of access response messages generated by servers when terminal devices access to the network. Here, the access response message refers to the Dynamic Host Configuration Protocol (DHCP) response message. Below, a brief introduction will be made about the DHCP.
Dynamic Host Configuration Protocol (DHCP):
The DHCP can be divided into two parts: one is the server end, while the other is the client end. DHCP servers run centralized management of all IP network setting information, and are responsible for dealing with DHCP requirements of the client end; while the client end uses IP environment information assigned from servers.
1. Assignment Forms of DHCP
At first, there must be at least one DHCP server working in the network. It monitors DHCP requirements of the network and negotiates with the client end about the setting environment of TCP/IP. Two kinds of IP positioning ways are provided:
automatic assignment, its circumstance is: once the DHCP client end has successfully leased an IP address from the DHCP server for the first time, it will use this address for ever;
dynamic assignment: once the DHCP client end has leased an IP address from the DHCP server for the first time, it doesn't use this address for ever. As long as the lease expires, the client end should release this IP address, so as to provide it to other work stations. Of course, the client end can renew the lease with higher priorities than other hosts, or lease other IP addresses.
2. Work Principle of DHCP
Depending on whether it is the first time for the client end to log on the network, the working form of DHCP will be different. Below, the working form of DHCP when it is the first time for the client end to log on the network will be detailed described with reference to FIG. 1.
Logging on the network for the first time:
1) Searching Server. When the DHCP end client logs on the network for the first time, namely the client finds there is no IP information setting in the host, it will send a DHCPDISCOVER packet to the network. Since the client hasn't known to which network it belongs yet, the source address of the packet is 0.0.0.0, and the destination address is 255.255.255.255, then the packet is attached with DHCPDISCOVER information and broadcasted to the network.
Under the circumstances of the Windows default setting, the waiting time of DHCPDISCOVER is preset as 1 second, namely after the client end has sent the first DHCPDISCOVER packet, if no response is obtained within 1 second, the second DHCPDISCOVER broadcast will be performed. Under the circumstances that no response is obtained all along, the client end will conduct totally four DHCPDISCOVER broadcasts (including the first DHCPDISCOVER broadcast), the waiting time for the first broadcast is 1 second, and the waiting time for the other three broadcasts is 9 seconds, 13 seconds and 16 seconds respectively. If there is still no response of the DHCP server, the client end will display error information and declares the failure of DHCPDISCOVER. After that, based on the choice of the user, the system will continue to repeat the DHCPDISCOVER process once again after 5 minutes.
2) Providing an IP lease address. After the DHCP server has monitored the DHCPDISCOVER broadcast sent by the client end, it will choose the most front unleased IP address from the range of the addresses which have not been leased, together with other TCP/IP settings, to form a DHCPDISCOVER packet and sent the same to the client end as a response.
Since the client end doesn't have IP address at the beginning, there is MAC address information contained in the DHCPDISCOVER packet, and there is an XID number to identify this packet. Based on this information, the DHCPOFFER packet responded by the DHCP server is forwarded to the client needing the lease. According to the setting of the server end, the DHCPOFFER packet contains information of the lease term.
3) Accepting an IP lease. If the client end receives responses of multiple DHCP servers in the network, it will only choose one of the DHCPOFFERs (generally the one that arrives earliest), and send a DHCPREQUEST broadcast packet to the network in order to tell all DHCP servers that it will accept the IP address provided by which server.
At the same time, the client end will also send an ARP packet to the network to enquire whether there are any other hosts using this IP address in the network; if it is found that this IP address has been occupied, the client end will send a DHCPDECLINE packet to the DHCP server, so as to decline to accept its DHCPOFFER and resend a DHCPDISCOVER message.
4) Acknowledging the lease. After the DHCP server has received the DHCPREQUEST of the client end, it will send a DHCPACK response to the client end in order to acknowledge that the IP lease has come into effect formally, namely a whole DHCP working process is completed.